This patent application includes microfiche Appendix A which is part of the present disclosure, and which is incorporated by reference herein in its entirety. This Appendix consists of a total of 5 sheets and contains a total of 409 frames. Appendix A includes listings of computer programs and related data including source code in the languages C++ and Perl for implementing runset generator that automatically generates DRC rules in one embodiment of this invention a s described more completely below.
A portion of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or record, but othrwise reserves all copyright rights whatsoever.
A computer programmed with appropriate software (called layout verification tool) is normally used to verify that a design of an integrated circuit (IC) chip conforms to certain predetermined tolerances that are required by a process to be used in fabricating the chip. Examples of such a layout verification tool include (1) HERCULES software available from Avant! Corporation, 46871 Bayside Parkway, Fremont, Calif. 94538, Tel 510.413.8000, and Web site www.avanticorp.com, (2) VAMPIRE software available from Cadence Design Systems, Inc, 555 River Oaks Parkway, San Jose, Calif. 95134, Tel 408.943.1234, and Web site www.cadence.com, and (3) CALIBRE software available from Mentor Graphics Corporation, 8005 SW Boeckman Road, Wilsonville, Oreg., 97070, Tel 503.685.7000, and Web site www.mentor.com.
Tolerances for the process that is to be used to fabricate the IC chip are often specified in the form of xe2x80x9crulesxe2x80x9d that are used by the layout verification tool to confirm that a chip""s design can be manufactured by the process (in an operation called xe2x80x9cdesign rule checkxe2x80x9d (DRC)). Examples of DRC rules to be used in checking an IC design include minimum width, minimum spacing between elements of a circuit, minimum width of notches, checks for acute angles and self-intersecting polygons, and enclosure and overlap checks. Such DRC rules can be applied to actual layers that are to be fabricated in the chip. Such DRC rules can also be applied to layers (called xe2x80x9cderived layersxe2x80x9d) that are formed by logical operations (such as not, and, or, and xor) on actual or derived layers or some combination thereof, as described in, for example, pages 164-166 of a book entitled xe2x80x9cPrinciples of CMOS VLSI Design, A Systems Perspective,xe2x80x9d second edition, by Neil H. E. Weste and Kamran Eshraghian, published by Addison-Wesley Publishing Company that is incorporated by reference herein in its entirety.
Such DRC rules may be supplied by the user through a graphical user interface (GUI), such as xe2x80x9ccomposerxe2x80x9d included in software called xe2x80x9cdw-2000xe2x80x9d available from Design Workshop Inc., 7405 Trans-Canada, Suite 320, St-Laurent, Quxc3xa9bec, Canada H4T 1Z2, Web site www.designw.com. DRC rules are normally stored in a computer file commonly called a xe2x80x9crunsetxe2x80x9d (also called xe2x80x9crule set.xe2x80x9d xe2x80x9crule file,xe2x80x9d xe2x80x9crule deck,xe2x80x9d or xe2x80x9crule scriptsxe2x80x9d). The runset is supplied as input to the layout verification tool to check if a design conforms to the DRC rules in the runset. The DRC rules are commonly expressed in a computer language that is specific to each layout verification tool (such as the xe2x80x9cStandard Verification Rules Formatxe2x80x9d (SVRF) used by CALIBRE, as described at Web site www.mentor.com/calibre/datasheets/calibre/index.html). According to Mentor Graphics, an SVRF optimizing compiler automatically tunes the order and type of operations performed during verification. These optimizations include eliminating redundant steps and combining similar operations into parallel computations.
Moreover, Mentor Graphics states at the above-described web site that an xe2x80x9cautomatic rule deck converterxe2x80x9d enables designers to get started right away, taking advantage of their existing rule decks. Such converters normally convert from the native language of one layout verification tool to the native language of another layout verification tool, thereby to allow the user to switch tools. Other such converters include utilities named A2drc (that translates the design rules from a Milkyway database to a Hercules DRC runset file) and A21vs (that translates netlist information from a Milkyway database to a Hercules LVS runset file) which are available in the HERCULES software (described above).
An approach in accordance with the invention adds a layer of abstraction to the generation of a runset for DRC rules, by defining a meta language that hides from the user the language of a specific verification tool (also called xe2x80x9cnative languagexe2x80x9d). The meta language can be used directly by the user to express in a file (also called xe2x80x9cmeta runsetxe2x80x9d) the DRC rules to be used to create an input for the verification tool in the native language (also called simply xe2x80x9crunsetxe2x80x9d). Alternatively the meta language can be built into a graphical user interface (GUI)) that receives information for the DRC rules from the user.
A runset generator in accordance with the invention (implemented by a suitably programmed computer) uses DRC rules supplied by a user to generate a runset in a native language (that is identified by the user). Use of such a runset generator enables an expert programmer who is knowledgeable about the native language to focus on difficult verification issues, while enabling a novice user who""s ignorant of the native language to perform the majority of tasks related to runset development and maintenance.
In one embodiment, a runset generator uses templates to generate a runset. Each template (also called xe2x80x9cDRC templatexe2x80x9d) contains code (can be in source form or in object form) for implementation of a DRC rule or derived layer in the native language of a specific verification tool (such as HERCULES). Thus implementation of DRC rules is hidden from the novice user. Such DRC templates can be written in an industry-standard language (such as C or C++), and dynamically loaded into the runset generator at runtime, thereby providing the user with the ability to add any number of additional DRC templates (e.g. to define new rules, new types of derived layers, or new verification tools).
As noted above, DRC templates of the type described herein capture the expertise of the template author for use by numerous novice users who do not need to learn the native language of a verification tool. Specifically, once a library of DRC templates exists, it is possible for a user who is totally unfamiliar with the native language to generate a runset using the runset generator with the library. Therefore, novice users having only a limited knowledge of verification can still contribute to the development and maintenance of runsets.
Also, using DRC templates ensures a consistent coding style and implementation in the runset. A single DRC template may be used numerous times in one or more runsets that are generated by the runset generator. Also, in one implementation, a single DRC template (that is fixed) is used for the generation of multiple DRC rules in the native language, each rule in the native language differing only by the parameters provided to the rule.
Use of DRC templates simplifies runset maintenance. For example, suppose a more efficient approach for implementing a DRC rule is found. To incorporate the change for all meta runsets containing this DRC rule, simply update the DRC template and regenerate all the runsets. Therefore, copy/paste errors in the prior art (that result from manual creation of runsets) are eliminated, and all runsets benefit from the enhancement, because the runsets are recreated using the runset generator.
Moreover, use of DRC templates streamlines the overall methodology used for runset development. It is no longer necessary to endure lengthy review sessions reading runsets in the native language. Instead, code in the native language for implementation of a DRC rule is captured in the corresponding DRC template, and the DRC template need be reviewed only once. Any changes in the DRC rule in a meta runset need only be verified to ensure that the data being input to the DRC template is correct.
In another embodiment, during automatic generation of DRC rules, the location in a runset of a derived layer specified by the user is optimized, by automatically inserting such a definition immediately prior to a DRC rule that uses the definition (also called xe2x80x9cjust in timexe2x80x9d layer definition). Such just-in-time layer definition reduces memory usage of the verification tool, and ensures that unused physical layers or derived layers do not appear in the automatically generated runset.
Note that the runset generator does not change the order of the DRC rules (although optimizing the order of layer definitions) thereby enabling a user to hierarchically structure the DRC rules in the meta runset in a manner most meaningful to the user. Such hierarchical structuring of rules in meta runsets enables the generation of native language runsets that are modular and contain only a portion of the complete set of DRC rules to be checked. These modular runsets simplify testing, and are also useful for reducing execution time of the verification tool when focusing on layout problems associated with violations of a small number of DRC rules.